[PATCH 11/36] cmd/libsnap-confine-private: Defend against hardlink attacks
authorAlex Murray <alex.murray@canonical.com>
Wed, 17 Nov 2021 03:57:22 +0000 (14:27 +1030)
committerMichael Vogt <mvo@debian.org>
Thu, 17 Feb 2022 15:29:46 +0000 (15:29 +0000)
commit8561877645ede04c86390acd8d83b88381669d17
treed8edb0590f8ba89043b0b1ab2e6c0e2f95207f46
parente0e21d5c5677fdb38b1bab770bc5c5cbf4871eb9
[PATCH 11/36] cmd/libsnap-confine-private: Defend against hardlink attacks

When snap-confine goes to execute other helper binaries (snap-update-ns
etc) via sc_open_snapd_tool(), these other binaries are located relative to
the currently executing snap-confine process via /proc/self/exe. Since it
is possible for regular users to hardlink setuid binaries when
fs.protected_hardlinks is 0, it is possible to hardlink snap-confine to
another location and then place an attacker controlled binary in place of
snap-update-ns and have this executed as root by snap-confine. Protect
against this by checking that snap-confine is located either within
/usr/lib/snapd or within the core or snapd snaps as expected.

This resolves CVE-2021-44730.

Signed-off-by: Alex Murray <alex.murray@canonical.com>
Gbp-Pq: Topic cve202144730
Gbp-Pq: Name 0011-cmd-libsnap-confine-private-Defend-against-hardlink-.patch
cmd/libsnap-confine-private/tool.c
cmd/libsnap-confine-private/utils-test.c
cmd/libsnap-confine-private/utils.c
cmd/libsnap-confine-private/utils.h